home *** CD-ROM | disk | FTP | other *** search
- Date: Wed, 12 Jan 94 10:04:53 -0500
- From: dsb@cs.duke.edu (Scott Bigham)
- Message-Id: <9401121504.AA24174@amazon.cs.duke.edu>
- To: mint@terminator.rs.itd.umich.edu
- Subject: Re: [MINTOS] compiler switch (was: Re: MiNT goes UNiX, ...)
-
- >The only information the __MINT__ switch provides, is that the target
- >operating system is MiNT rather than pure Gemdos.
-
- Not even that much, in fact; all it says is that the code is being
- compiled with the MiNTlibs. The libs do a lot of backward-bending to
- handle TOS environments.
-
- > What we need is a switch
- >that tells a bit more about the target system in general: for example that
- >reasonable filesystems (like minixfs) will be used (no need to mess around
- >with filenames like bison.simple or .profile), and that the environment
- >variables should follow the Unix conventions (PATH, MANPATH, etc.).
-
- But that's not the point. I'm trying to write code that runs on a
- GEMDOS filesystem but takes advantage of MinixFS if it's present; that
- runs under TOS but takes advantage of MiNT if it's present; and so on.
- I don't want to limit the utility of the programs I write to just us
- UNIX freaks ;) , and I don't want to have to build a different version
- of my programs for every kind of target system someone might want to
- run them on.. That means runtime checks of the local system's setup,
- and I think __MINT__ is still the most appropriate #ifdef to wrap those
- checks in.
-
- >There shouldn't be any compiler dependent code in an application, that's
- >what the P1003.1 types (size_t, ssize_t, clock_t, ...) are all about.
-
- Heh. Were it only so simple. Many's the time I've had to add some
- #ifdef __HSC__'d lines to kludge around features that HSC simply didn't
- support (really large arrays, for instance).
-
- -sbigham
-